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(54) 



(57) A method and apparatus for resynchronizing a 
network manager to its agents. Each object instance of 
an agent in an object-oriented management scheme is 
assigned two special attributes, namely, DATASYNCH 
and UNIQUEID. UNIQUEID is a unique number as- 
signed to each object instance. DATASYNCH essential- 
ly is a counter which is incremented each time a change 
occurs to an object instance. When ^synchronization 



is necessary, the manager requests the UNIQUEID and 
DATASYNCH attributes from its agents and compares 
those values with the corresponding values stored in its 
database. With respect to any object instance which 
does not match in both its UNIQUEID and DATASYNCH 
attributes to the manager's database, the manager up- 
loads those object instances from the agent's database 
and/or revises its database accordingly. 



FIG. 1 
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Description 

FIELD OF THE INVENTION 

[0001] The invention pertains to network communica- 
tion systems. More particularly, the invention pertains to 
a method and apparatus for re-synchronizing a network 
manager to its agents. 

BACKGROUND OF THE INVENTION 

[0002] Communications networks with a significant 
number of communication nodes typically employ a 
manager/agent scheme to control communications be- 
tween the network communication nodes. In such 
schemes, the communication nodes are termed 
"agents", while the nodes which manage communica- 
tions on the network are termed "managers". 
[0003] Figure 1 illustrates one common type of com- 
munications network 1 0 and control scheme therefor, in- 
cluding a plurality of managers 4 which each manage a 
plurality of agents 6. The plurality of managers 4 may 
be connected to each other in any one of a number of 
configurations, including tree (as shown) and star con- 
figurations. The various managers 4 may communicate 
with each other through a higher level node, termed a 
network manager 2 N (as illustrated), which communi- 
cates with all of the managers and the overall network. 
In other schemes, the managers 4 may communicate 
directly with each other (not shown). Each node 2, 4, 6 
on the network typically will include some type of data 
processing unit, 2a. 4a, and 6a and memory. As an ex- 
emplary illustration in Figure 1, each node 2, 4, 6 has 
both ROM 2b, 4b and 6b as well as RAM 2c } 4c and 6c. 
Each node also should include a separate database 
memory, 2d : 4d : and6d, for at least network operational 
data. 

[0004] In an object-oriented management scheme, 
each agent 6 maintains a Management Information da- 
taBase (Ml B) in database memories 6d that contains the 
condition of all of the attributes (commonly termed ob- 
ject instances) of all of the objects of that agent. The 
managers 4 usually also maintain in database memo- 
ries 4d a putative copy of the MIB of each agent under 
its management control. The copy stored at the manag- 
er is deemed putative since it may not be identical to the 
data stored at the agent. The agent's MIB data is as- 
sumed to be the most correct copy of the MIB. 
[0005] As long as the copy of the MIB for an agent 
stored at the manager is identical to the MIB stored by 
the agent, the manager and the agent are synchronized. 
However, various events can occur which would cause 
the manager to either lose synchronization with one or 
more of its agents or, at least, not know whether it is 
synchronized to one or more of its agents. For instance, 
the manager may simply become disabled for a period 
of time during which object instances of its agents may 
be changed, added or deleted Also, it is possible for a 
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communication link (or association) between a manager 
and an agent to go down for a period of time. In either 
event, the manager, when it re-establishes an associa- 
tion with the agent, will not know if its putative copy of 
5 the agent's object instances is current, and will need to 
confirm and/or update its database in accordance with 
any changes that occurred during the period of non- 
communication with the agent. 

[0006] In one prior art ^synchronization scheme, 
10 each agent maintains an event log in which each and 
every creation, deletion or change in state of an object 
instance is recorded. Whenever an event occurs , it is 
stored in the event log. Also, an M event report is sent 
from the agent to the manager informing it of the event 
15 There usually is no confirmation of M event reports by 
the manager. The manager will update its relevant copy 
of the object instances for the agent accordingly. How- 
ever, if the communication association between the 
manager and the agent is down, the manager will not 
20 receive the Event Report and, therefore, will no longer 
be synchronized with the agent. 

[0007] The object instances in the event log are 
tagged with, for instance, a time-stamp. The event log 
is maintained in a circular buffer. After communication 
2S between a manager and an agent is re-established, the 
manager can check the event log and read out every 
entry in the event log having a tag indicating that the 
event occurred after the time that the association was 
lost This type of resynchronization scheme can be ex- 
30 tremely time consuming if the number of events which 
occurred during the loss of association is significant. In 
fact, the loss of an association between a manager and 
an agent is frequently caused by, or at least associated 
with, a problem in the system that will lead to a signifi- 
es cant number of other network events, including changes 
in the object instances of the agents. Accordingly, a sig- 
nificant number of changes in object instances of the 
agents frequently occurs precisely when a communica- 
tion association is lost between a manager and an 
40 agent. As an example, the MIB in present network sys- 
tems typically may have between 500 and 1 0,000 object 
instances per agent. Smaller object instances may have 
on the order of 200 to 400 bytes each However, larger 
ones can have 5,000 to 8.000 bytes of information. Fu- 
45 ture network systems are projected to have substantially 
increased numbers and sizes of object instances. Ac- 
cordingly, resynchronization can be rather time consum- 
ing. 

[0008] If the number of events occurring during a loss 
50 of association between a manager and an agent ex- 
ceeds the length of the log, the log can no longer be 
used for resynchronization, since the earliest events are 
lost. In such a case, resynchronization can be achieved 
only by reading the entire MIB database out of the agent 
55 into the manager. 

[0009] Accordingly, it is an object of the present inven- 
tion to provide an improved resynchronization scheme 
for a network 
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[0010] It is another object of the present invention to 
provide a resynchronization scheme tor a network in 
which the amount of data which must be exchanged to 
achieve ^synchronization is substantially reduced. 

SUMMARY OF THE INVENTION 

[0011] In the present invention, each object instance 
stored in the MIB of an agent contains two additional 
attributes, termed "UNIQUEID" and "DATASYNCH". 
UNIQUEID is a unique number assigned to each object 
instance when it is created. Preferably the UNIQUEID 
attribute is of sufficient bit length to assure that, in any 
practical situation, there are more unique ID'S available 
than possible object instances for the agent. 
[0012] DATASYNCH is a number assigned to each 
object instance upon creation. Typically, the number as- 
signed upon creation will be 0 or 1 . Each time that object 
instance is updated, DATASYNCH is incremented by 1. 
As with UNIQUEID, the bit length of the DATASYNCH 
attribute preferably is enough to handle any practical 
number of changes that might occur to an object in- 
stance during a loss of association. 
[0013] When resynchronization is necessary, the 
manager will poll the agent requesting a copy of the 
UNIQUEID and DATASYNCH attributes for each object 
instance in the agent's MIB. While the agent is generat- 
ing this report and communicating it to the manager, the 
manager is likewise preparing a similar report of each 
UNIQUEID and DATASYNCH attribute stored in its da- 
tabase. 

[0014] The manager then compares the UNIQUEID 
and DATASYNCH attribute values received from the 
agent to its putative copy of the UNIQUEID and DATA- 
SYNCH values for the object instance for that agent. 
[0015] For each UNIQUEID which the manager has 
in its database that does not have a corresponding 
UNIQUEID at the agent, the manager will delete that ob- 
ject instance from its database. For each object instance 
detected at the agent for which the manager does not 
have a corresponding UNIQUEID or that has a DATA- 
SYNCH attribute value different from the DATASYNCH 
attribute value stored at the manager, the manager 
reads the entire object instance from the agent and up- 
dates its corresponding object instance accordingly, in- 
cluding updating the UNIQUEID and DATASYNCH val- 
ues. No action is taken with respect to object instances 
for which both the UNIQUEID and DATASYNCH at- 
tributes match. 

[001 6] The manager is resynchronized to the fault sta- 
tus of the agent by requesting each active fault status 
from the agent and updating its database accordingly. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0017] Figure 1 is a block diagram of an exemplary 
communications network. 

[0018] Figure 2 is a message flow diagram of the re- 



synchronization interaction. 

[0019] Figure 3 is a message flow diagram of the man- 
ager resynchronization scheme with respect to an ex- 
isting object instance. 

s [0020] Figure 4 is a message flow diagram of the man- 
ager resynchronization scheme with respect to an ob- 
ject instance that was created during a loss of associa- 
tion between the agent and the manager 
[0021] Figure 5 is a message flow diagram illustrating 

10 resynchronization of fault status. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT OF THE INVENTION 

75 [0022] The description herein of exemplary embodi- 
ments of the invention specifically pertains to networks 
in accordance with the ITU-T international standards, 
which are incorporated herein by reference, and as- 
sumes a familiarity with those standards, particularly 

20 sections x21 7 and x.700etseq. It should be understood, 
however, that the invention is not limited to networks in 
accordance with the aforementioned standard or to the 
specific embodiments described herein, which are 
merely exemplary and not limiting. As mentioned above, 

2S there are many circumstances in which the communica- 
tion link (or association) between a manager 4 and an 
agent 6 is lost; justifying a resynchronization operation. 
For instance, resynchronization may be necessary after 
any break in the communication link between the man- 

30 ager 4 and its agent 6, such as may be caused by a 
break or failure in either the manager 6, the agent or the 
communication medium 8 therebetween. Also, resyn- 
chronization may be necessary after a lengthy upload, 
during which time changes may have occurred at the 

3S agent which could not be communicated to the manager 
due to the use of the communication channels for the 
upload. 

[0023] Also, a system user may manually request a 
resynchronization operation and/or the agent may au- 
40 tomatically request resynchronization under various cir- 
cumstances. 

[0024] As noted above, the present invention is adapt- 
ed for use in an object-oriented management scheme. 
In an object-oriented method, each agent is described 

45 as a collection of objects inside a container. The agent 
(or network element) stores in its memory 6c its condi- 
tion (i.e., the information needed by itself and other net- 
work elements for it to operate and communicate on the 
network) in a series of stored object instances. For ex- 

^0 ample, if a particular agent is a personal computer (PC) 
connected to the network, exemplary object instances 
might be the identity and configuration of each card or 
peripheral device installed on the PC . An object instance 
may have further object instances of its own. For exam- 

55 pie, if the exemplary PC (which is an object instance it- 
self) has a CD-ROM player, one object instance con- 
tained by the PC object instance would be the CD-ROM 
object instance. The information contained therein 
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would d.sclose the configuration and attributes of the 
CD-ROM player, such as its speed and its drive letter 
The agent stores this information in a MIB (Management 
Information Base) database in database memory 6d In 
order to properly manage its agents 6, a manager 4 s 
maintains a putative copy of the MIB database in data- 
base memory 4d. 

[002SJ Changes to an object instance can occur in 
one of two ways. The manager 4 may cause a change 
to an object instance by sending an M Set instruction w 
wh.ch basically informs the agent 6 to set a certain ob- 
ject instance to a particular condition. Alternately, the 
manager 4 can send an M Action instruction to an agent 
6 instructing the agent to perform some function That 
function might cause the agent 6 to change an object is 
instance. In either event, each time an object instance 

mir H 3t , e k del6,ed ° r a ' ,ered ' the a 9 ent 6 "P^tes its 
MIB database accordingly and also sends an M Event 

Report to its manager 4 notifying it of the change The 
manager 4 then updates its copy of the MIB database so 
for that particular agent accordingly. | n any circum- 
stance ,n which M Event Reports issued by an agent 6 

ll^^'T ^ mana9er 4 ' synchronization 
should be performed. For instance, while communica- 
tion between a manager and its agent is down, it is pos- 2s 
s.ble that a peer manager on the network may assume 
control of the agent during this down time. In fact our 
Application No. GB 9717030 9 entitled GEOGRAPHIC 
REDUNDANCY PROTECTION METHOD AND APPA 
RATUS FOR A COMMUNICATIONS NETWORK and 30 
Wed on even date herewith, describes a scheme under 
which this may occur, incorporated herein by reference 
When t he or|gjna| manager re . estab)jshes assocjatjon 

wrth the agent, ,t will need to resynchronize with it 
[0026] m accordance with the present invention, each 35 
object instance stored in the MIB of an agent 6 is as- 
signed two additional attributes, termed "UNIQUEID" 

sTon Sf^??" UN ' QUEID ,S 3 Uni « ue "^-as- 
signed to each object instance when it is created Pref- 
erably the UNIQUEID attribute is of sufficient bit lengt 40 
to assure that, ,n any practical situation, there are more 
umque ID's available than possible object instances for 

UN.ofS M h ! PreS6n,ly preferred embodiment. 
UNIQUEID ,s 15 brts in length and, therefore, can ac- 

an a^S? 16 °™ 32 '°°° 0h,eCl inS,ances ? er a 9ent. As « 
an added precaution against twoobject instances being 
assigned the same UNIQUEID, it more than 32,000 ob 
ject instances are created in an agentdomain, the soft- 
ware at the agent will look for holes in the UNIQUEIDs 

and 5 T 00 ? ,hat W6re Creat6d and theri dele ^d) so 

UMQUPtn h ° leS " ° rder t0 continue 10 ass " a 'ha 
UNIQUEID remains unique for each existing object in- 
stance in the MIB database 

S UN ' QUE,DisaG ^onlyat.ribute. In particular, 
Lv the m T ^ '! " 3n a,,ribU,e that ca ™ ot b * changed ss 
This further assures uniqueness 

[0028] DATASYNCH is a number assigned to each 



object instance upon creation. Typically, the number as- 
signed upon creation will be 0 or 1 . Each time that object 
instance is updated, DATASYNCH is incremented by 

Zl£ W * b UN,QUEID - the b " ,en 9 th of the DATA- 
SYNCH attribute preferably is sufficient to handle any 
practical number of changes that might occur to an ob- 
ject instance during a down time. In a preferred embod- 
iment, DATASYNCH also is 1 5 bits long. 
[0029] The following discussion pertains to one man- 
ager resynchronizing with one agent. However, it should 
be understood that, in the preferred embodiment all 
managers 4 have the discussed capabilities and that 
each manager4can perform ^synchronization with any 
one or more of its agents 6. 

[0030] When resynchronization is necessary the 
manager 4 will poll the agent 6 requesting a copy of the 
UNIQUEID and DATASYNCH attribute for each object 
instance in the agent's MIB database 6d While the 
agent .s generating this report and communicating it to 
the manager, the manager is likewise preparing a similar 
report of each UNIQUEID and DATASYNCH attribute 
stored in its database 4d. 

[0031] After both reports have been generated and 
the agent 6 has sent its report to the manager 4 the 
manager 4 compares its report with the report received 
from the agent 6. 

fn °f 2 l ^ eaCh UNIQUE,D th *t the manager 4 has 

UNIQUE n ft 6 ,hat **" ^ haVS 3 —'ponding 
UNIQUEI D at the agent 6, the manager 4 will delete that 
object instance from its database. For each object in- 
stance detected at the agent 6 for which the manager 4 
does not have a corresponding UNIQUEID, the manao- 
er 4 will read the entire object instance from the agent 
6 and update its corresponding object instance accord- 
ingly including updating the UNIQUEID and DATA- 
SYNCH values. For each object instance for which the 
manager 4 and agent 6 have a matching UNIQUE ID 
value, but non-matching DATASYNCH values the man- 
ager 4 will read the entire object instance from the agent 
6 and update its corresponding object instance accord- 

S' ' nc,udin 9 u P datin 9 the UNIQUEID and DATA- 
oYMCrl values. 

f?M.oL,^° r 6aCh 0bj9Ct instan ce for which both the 
UNIQUE D and DATASYNCH attributes match, no ac 
tion is taken. 

at anlLntS ° f UmeS an **« instanc e 

wHh it?™ haSbeenrev,sedduri "9alossof association 
with its manager is exactly equal to the maximum pos- 
sible value of the DATASYNCH attribute (i e 2 « = 

SylcHV^^^ embodirner "t which DATA- 
SYNCH is 15 bits ,n length), then the DATASYNCH at- 

^,! ,0r f dbytne mana 9 er will match with the DATA- 
SYNCH value stored by the agent, even though the cor- 
responding object instance actually has been revised at 

r dSH M emeS may 66 US6d in ° rderto datec t such 
32 768 Z\ ^ SlnCe th6 l,kelih00d of exa c% 

Sw!L OCCUrrin9 dUrina a loss <* association 

between an agent and its manager are diminishingly 
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small, in the preferred embodiment of the invention, no 
protection is provided for this almost non-existent error 
source. 

[0035] Figures 1-5 illustrate a preferred implementa- 
tion of the present invention. In one embodiment ol the 
invention, each agent has three attributes that are rele- 
vant to the present invention, namely, management 
state, MIBstate and Ml Block. The management state at- 
tribute has several possible states of which only a few 
are relevant to the present invention. The management 
state basically conveys the state of the agent in terms 
of the general operation which is currently being under- 
taken. For instance, when the agent is operating in its 
normal operating condition and is available for commu- 
nication, the management state is NORMAL. The man- 
agement state also could be RESYNCHING, indicating 
that a resynchronization operation of object instances 
in accordance with the present invention is currently be- 
ing performed, or REEVALUATINGFAULTSTATUS, in- 
dicating that the agent is updating its manager to the 
current active fault conditions of the agent. Other pos- 
sible exemplary management states that are possible 
include UPLOADING and DOWNLOADING. The man- 
agement state generally informs the other nodes on the 
network that might attempt to communicate with the 
agent of its present state. 

[0036] The Ml Block attribute may have two condi- 
tions, namely, LOCKED and UNLOCKED. LOCKED 
means that the M1B database is presently inaccessible 
and that no changes may be made thereto at this time 
UNLOCKED means that the MIB database can be up- 
dated. 

[0037] The MIBstate denotes the agent's view of the 
state of its MIB database. MIBfilled indicates that the 
MIB database is full and can be resynchronized with the 
manager. MIBempty indicates that the agent's MIB da- 
tabase is empty. Ml Bempty means that the manager and 
agent cannot resynchronize to each other using the 
method and apparatus of the present invention. Rather, 
the manager must download its putative copy of the Ml B 
database for that agent to the agent. 
[0038] Figure 2 is a message flow diagram generally 
illustrating the overall resynchronization process. Under 
normal conditions, the management state and MIBstate 
of the agent are NORMAL and MIBFILLED, respective- 
ly, as shown at 15. In the first step 16, the manager 12 
sends a Ml BRESYNC (confirmed) M-Action to agentdo- 
main in the agent. Assuming that the agentdomain's 
managementstate is NORMAL and its MIBstate is 
MIBFILLED, it sends a confirmation 14 back to the man- 
ager. If either of these conditions is not met, it rejects 
the Ml BRESYNC M-ACTION (not shown). 
[0039] Assuming that agentdomain responds with a 
MIBRESYNC confirmation 16, the agent also changes 
its managementstate to RESYNCHING and its MIBstate 
to LOCKED, as shown at 1 9. A managementstate of RE- 
SYNCHING informs any other object attempting to com- 
municate with the agent that it is resynching. The 
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LOCKED condition of MIBIock will prevent the MIBstate 
from changing during resynchronization. 
[0040] Next, the agent sends an M event report 20 to 
the manager indicating that it has changed its manage- 

5 mentstate and MIBstate as indicated. Then, the agent 
compiles the UNIQUEID and DATASYNCH data for 
transmission to the manager, as indicated at 22. The 
Agentdomain object instance then sends the UNIQUE- 
ID and DATASYNCH values to the manager by sending 

io one or more MIBSYNCHDATA notification packets 24. 
MIBSYNCHDATA packets 24 may be M-E VENT-RE- 
PORTS in accordance with ITU-T standard sections x. 
710 et seq. Each packet also contains information as to 
whether it is an intermediate packet 24a or the last pack- 

75 et 24b. After the final packet 24b, the agent 14 sets its 
managementstate and MIBstate attributes back to 
NORMAL and UNLOCKED, respectively, as shown at 
25 and sends an M Event Report 27 to the manager 12 
informing it of the changes. 

20 [0041] As disclosed more fully below in connection 
with Figures 3-4, the manager then compares the 
UNIQUEID and DATASYNCH information receivedfrom 
the agent with its own UNIQUEID and DATASYNCH in- 
formation. 

25 [0042] For existing object instances with matching 
UNIQUEIDs and DATASYNCH values, no action is per- 
formed (no figure provided). 

[0043] For object instances that exist in the manager's 
MIBstate database, but for which no corresponding 
30 MIBsynchdata notification is received, the manager de- 
letes its image of the object instance (no figure provid- 
ed). 

[0044] Figure 3 is a message flow diagram illustrating 
operation when the manager detects an existing object 

35 instance with a non-matching DATASYNCH value, as 
shown at 26 in Figure 3. The manager 1 2 first sends an 
M-GET request 28 for all attributes of that object in- 
stance. The agent 14 responds to the request by gen- 
erating the requested data for transmission, as shown 

40 at 30. When ready, the agent 14 responds to the man- 
ager 12 with an M-GET confirmation 32 transmitting the 
requested data. The manager then replaces the object 
instance data in its database with the new information, 
as shown at 33. The operation is repeated for each such 

45 object instance for which the corresponding DATA- 
SYNCH values do not match. 

[0045] Figure 4 illustrates operation 1or object instanc- 
es that are received in a MIBsynchdata notification from 
the agent, but for which there is no corresponding object 

50 instance in the manager's MIBstate database i.e., for 
which there is no matching UNIQUIED. Specifically, the 
manager 12 determines that the agent has sent a 
UNIQUEID for which it does not have a corresponding 
UNIQUEID, as shown at 34. It then sends a SCOPEDG- 

55 et M-ACTION 36 for the corresponding object instance. 
The agent responds with a confirmation 38 followed by 
the requested data, which is sent in an M Event Report 
40. The SCOPEDGet action filters for the given 
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UNIQUEID to obtain the full details of the object in- 
stance. 

[0046] If the association between the manager and 
the agent is dropped during the resynchronization oper- 
ation, the agent will return its managementstate to NOR- 
MAL. The resynchronization can then be performed 
again when the association is reestablished with no ad- 
verse affects to the resynchronization operation. 
[0047] When a manager must resynch with more than 
one of its agents, the resynchronization process will be 
performed sequentially for all of the agents, with the or- 
der based on the value of the agentdomain, starting at 
agentdomainl D = 1 . In the event of an association failure 
when performing a resynchronization on multiple 
agents, the manager will re-do the entire process of re- 
synchronization with all agents starting with agentdo- 
mainl D = 1 again. 

[0048] For all node types, if the resynchronization 
process fails, the current association will be aborted and 
the manager will attempt reassociation. 
[0049] In a preferred embodiment of the invention, 
whenever resychronization occurs, the manager also 
resynchronizes with respect to faults which may have 
occurred during the loss of association. Referring to Fig- 
ure 5, the manager will request a faultstatus resynchro- 
nization by sending a REEVALUATE FAULTSTATUS IN- 
ACTION 42 to eventcontrol in the agent. The request is 
confirmed by the agent 44. The agent will then change 
its managementstate of the affected agentdomain to 
REE VALU ATI NGFAULT STATUS and change its 
MIBstate to LOCKED. It will then notify the manager of 
this action with an M Event Report 46. 
[0050] Next, the agent collects and compiles the re- 
quested information, as shown at 48. Each object in- 
stance in the agent that has one or more active faults 
sends a CURRENTFAULTSTATUS notification 50 for 
each active fault. After all the CURRENTFAULTSTA- 
TUS notifications 50 have been sent, the agent sends 
a RE-EVALUATEFAULTSTATUS-COMPLETE notifica- 
tion 52 for that agentdomain to indicate the end of the 
operation. CURRENTFAULTSTATUS notification 50 
and RE-EVALUATEFAULTSTATUS-COMPLETE notifi- 
cation 52 may be M_EVENT REPORTS under the ITU- 
T standard (see sections x.710 and x.711). The agent 
will then set its management state back to NORMAL and 
its MIBstate back to UNLOCKED (of the affected agent- 
domain) and notify the manager of these actions with 
an M Event Report 54. 

[0051] In the most typical situations where resynchro- 
nization is required, resynchronization by the method 
and apparatus of the present invention requires the 
transmission of orders of magnitude less data than in 
the prior art system in which the event log of the agent 
is read out by the manager. In a worst case scenario, it 
is projected that the method and operation of the present 
invention may transmit approximately the same amount 
of data as the prior art event log method. However in a 
more typical situation, the amount of data transferred to 



15 



perform a resynchronization will be orders of magnitude 
less than in the prior art event log type scheme. 
[0052] With respect to the updating of the fault status 
of an agent, the method and apparatus disclosing the 
invention will show improved reduction in data transfer 
relative to the prior art fault event log method as the du- 
ration of the loss of association increases. 
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1 . A method of resynchronizing a network manager to 
a network agent in a data communication network 
in which managers maintain a putative copy of data 
describing said agent, said method comprising the 
steps of: 

(1 ) storing at said agent, for each individual unit 
of data describing said agent, a first value cor- 
responding to each unit of data, said first value 
being unique for every said unit of data; 

(2) storing at said agent, for each of said units 
of data ; a second value that indicates the 
number of times that the corresponding unit of 
data has been changed; 

(3) storing at said manager a putative copy of 
said first and second values; 

(4) comparing said first and second values 
stored at said agent with said corresponding 
first and second values, respectively, stored at 
said manager; and 

(5) for every unit of data for which said first and 
second values stored at the manager do not 
match the first and second values, respectively, 
stored at the agent, revising the unit of data 
stored at the manager. 

2. A method as set forth in claim 1 wherein step (5) 
comprises the steps of; 

(5.1) replacing the corresponding unit of data 
stored at the manager with a copy of the corre- 
sponding unit of data stored at the agent, if the 
corresponding first values match and the cor- 
responding second values do not match; 

(5.2) deleting the corresponding unit of data 
stored at the manager, if the manager has a first 
value and the agent does not have a matching 
first value; and 

(5.3) adding at the manager a copy at the man- 
ager of the corresponding unit of data from the 
agent, if the agent has a first value for which 
the manager does not have a matching first val- 
ue. 

3. A method as claimed in claim 1 or claim 2 wherein 
said network is an object oriented data communica- 
tion network and said units of data are object in- 
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stances. 

4. An apparatus for resynchronizing a network man- 
ager to a network agent in an object oriented data 
communication network, comprising: s 

a first memory in said agent for storing a plural- 
ity of object instances describing said agent, 
each said object instance including a UNIQUE- 
ID attribute that is unique for each object in- io 
stance and a DATASYNCH attribute that indi- 
cates the number of times that the correspond- 
ing object instance has been changed; 
a second memory in said manager for storing 
a putative copy of said plurality of object in- is 
stances, including said UNIQUEID and DATA- 
SYNCH attributes; and 

a processing unit at said manager for compar- 
ing said UNIQUEID and DATASYNCH at- 
tributes stored at said agent with said corre- 20 
spending UNIQUEID and DATASYNCH at- 
tributes stored at said agent, respectively, upon 
resynchronization and for every object instance 
for which the corresponding UNIQUEID and 
DATASYNCH attributes stored at the manager 2s 
do not match the UNIQUEID and DATASYNCH 
attributes, respectively, stored at the agent, re- 
vising the object instance stored at the manag- 
er. 

30 

5. An apparatus as set forth in claim 4 wherein said 
processing unit of said manager further comprises: 

means for replacing the corresponding object 
instance stored at the manager with a copy of 35 
the corresponding object instance stored at the 
agent, if the corresponding UNIQUEID at- 
tributes match and the corresponding DATA- 
SYNCH attributes do not match; 
means for deleting the corresponding object in- 40 
stance, if the manager has a UNIQUEID at- 
tribute for which the agent does not have a 
matching UNIQUEID attribute; and 
means for adding a copy of the corresponding 
object instance of the agent, if the agent has. a 45 
UNIQUEID attribute for which the manager 
does not have a matching UNIQUEID attribute. 
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